Analysis for Concurrent Objects

locations, e.g. , g for lg and b for lb . To formalize our analysis, we need to introduce a bit more notation. Given a program P , let VarP be the set of variables occurring in P . Let VarO be the set of variables labelling possible object creation points occurring in P . Let d HvalP be the set of abstract heap values of P . Let Pfin be the nite power-set constructor, and let mt(a) denote the method table of object a in . We now de ne the environments H, A for P and the relation P j= H;A, which establishes the conditions under which H;A are valid for P . In particular, the relation P j= H;A holds if H;A are valid approximations of every heap, object soup combination H; produced during any execution of P . De nition 2 Let P be a program. A set environment for P is a mapping H : VarP ! Pfin(d HvalP ). A set object environment for P is a mapping A : VarO ! Pfin( d MeTable). P j= H;A holds if gP 7 ! DD H j j EE implies H; j= H;A. H; j= H;A holds if for all bindings (lx = h) 2 H z 2 H(x) and mt(az) 2 Cl(A(z)) if h = az h 2 Cl(H(x)) otherwise where Cl(v̂) = fv̂[x1 lx1 ; : : : ; xn lxn ] jFV [v̂] = fx1; : : : ; xng; and lxi 2 Locxig 5.1 Set Constraints Having de ned what we mean by valid environments for a program P , we need to be able to compute such environments. To that end, we generate from P a collection of set constraints such that anyH and A satisfying these constraints are valid for P . Properties of the constraints for P guarantee they have a least solution. A proof of the existence of a least solution and an algorithm that computes it can be found in (Di Blasio 1997). Given a program P , a set constraint is composed of a premise AP which concerns the environmentsH;A and the program P , and a conclusion B which concerns only the environments H;A. A pair of environments H;A satis es such a set constraint relative to P if whenever AP holds for H;A and P , then B also holds for H;A. Before proceeding with the constraints, we rst introduce some notation. We write M 2 P , to indicate that M is an ANF term that occurs in P . Given an abstract method table ̂, ̂0 = ̂[m = (w; z)] is equal to ̂ except for the entry m; in this case, ̂0(m) = (w; z) (see CP ov, CP ext constraints in Figure 2). The empty abstract method table is denoted by ̂;. Function FinalVar, de ned below, computes for any ANF term M the variable whose value will be the result of reducing M . CP const (let x = c in M) 2 P c 2 H(x) CP lamb (let x = y:N in M) 2 P y:N 2 H(x) CP emp obj (let x = hi in M) 2 P x 2 H(x) ̂; 2 A(x) CP var (let x = N in M) 2 P H(FinalVar[N ]) H(x) CP apply (let x = y z in M) 2 P w:N 2 H(y) H(z) H(w) H(FinalVar[N ]) H(x) CP ext (let x = hy + m = when(w)zi in M) 2 P y0 2 H(y) ̂ 2 A(y0) x 2 H(x) ̂0 2 A(x) CP ov (let x = hy m = when(w)zi in M) 2 P y0 2 H(y) ̂ 2 A(y0) x 2 H(x) ̂0 2 A(x) y0 2 H(x) ̂0 2 A(y0) CP s inv (let x = y(sm(z) in M) 2 P y0 2 H(y) ̂ 2 A(y0) ̂(m) = (g; b) s1: N1 2 H(g) s2: N2 2 H(b) w:N3 2 H(FinalVar[N2]) H(y) H(s1) H(y) H(s2) H(z) H(w) H(FinalVar[N3]) H(x) CP as inv (let x = y(am(z) in M) 2 P y0 2 H(y) ̂ 2 A(y0) ̂(m) = (g; b) s1: N1 2 H(g) s2: N2 2 H(b) w:N3 2 H(FinalVar[N2]) H(y) H(s1) H(y) H(s2) H(z) H(w) nil 2 H(x) Figure 2 Set constraints for A-normal-form expressions De nition 3 The function FinalVar on ANF terms is de ned as follows: FinalVar[x] = FinalVar[lx] = x FinalVar[let x = : : : in M ] = FinalVar[M ] Figure 2 shows the set constraints for our language. In the following, we give the intuition behind the soundness of some of the constraints. (CP emp obj) When we execute let x = hi in M , the value associated with x is a new object address ax, and the method table of the created object is empty. Thus we add x to H(x) and ̂; to A(x). (CP var) When we execute let x = N in M , the value associated with x is the value of the return variable of N . Thus we add the constraint H(FinalVar[N ]) H(x). (CP apply) The two constraints on the value sets in the conclusion represent respectively the ow of values from the actual to the formal parameter of the function and from the variable containing the result of the function, FinalVar[N ], to the variable x. (CP ext;ov) When we execute let x = hly m = when(lw)lzi in M , where is either + or the non-self-in icted version of , the value associated with x is a new address ax; thus we add x to H(x). The method table of ax is obtained by adding m = (lw; lz) to the method table of object ay0 , where ay0 = H(ly). Thus we add ̂0 = ̂[m = (w; z)] to A(x). In CP ov, we must further consider the case that the operation is self-in icted. Here, the value associated with x is H(ly) = ay0 . Thus we add y0 to H(x). Since ay0 has a new method table obtained by overriding method m in with the new pair (lw; lz), we add ̂0 = ̂[m = (w; z)] to A(y0). (CP s;as inv) The execution of a synchronous method invocation may result in the application of a guard and a body. The constraint H(y) H(s1) represents the ow of values from the actual to the formal parameter in the guard function. The method body application is a generalization of the function application case. It consists of a double application. Thus the second and third constraint in the conclusion represent the ow of values during input, while the fourth constraint represents the return ow. For the asynchronous method invocation case the value nil is returned immediately. Thus we add nil to H(x). 5.2 Examples Inlining. To show how set-based analysis works and its possible applications, we consider the following ANF of the program described in Section 2. let o3 = hi in let l1 = s1: N1 in let o4 = ho3 + m1 = l1i in let l2 = s2: N2 in let o1 = ho4 + m2 = l2i in let l3 = s3: N3 in let o2 = ho1 m2 = l3i in let f = x:N4 in let x1 = f o1 in x1 where N2 let f2 = a2: N 0 2 in f2, N 0 2 let i1 = s2(am1( ) in i1, and N4 let i2 = x(am2( ) in i2 and N1; N3 are ANFs of e1; e3 respectively. We apply the set constraints in Section 5.1 to the program in ANF. Some of the resulting constraints, one for each type of expression in the example, are showed in Figure 3. We annotate each constraint with the name of the set constraint that produced it and with the variable denoting the expression to which the constraint was applied. We assume that the unspeci ed code Set Constraints CP emp obj on o3: o3 2 H(o3), ; 2 A(o3) CP lamb on l1: s1:N1 2 H(l1) CP ext on o4: o4 2 H(o4), and for all y0 2 H(o3), ̂ 2 A(y0), ̂[m1 = ( ; l1)] 2 A(o4) CP as inv on i1: for all y0 2 H(s2) and ̂ 2 A(y0), with ̂(m1) = ( ; b) and s:N 2 H(b), we have H(s2) H(s) and nil 2 H(i1) CP ov on o2: o2 2 H(o2), and for all y0 2 H(o1) and ̂ 2 A(y0), we have y0 2 H(o2), ̂[m2 = ( ; l3)] 2 A(o2), and ̂[m2 = ( ; l3)] 2 A(y0) CP apply on x1: for all w:N 2 H(f), H(o1) H(w), H(FinalV ar[N ]) H(x1) Set environment H(o1) = fo1g H(o2) = fo1; o2g H(o3) = fo3g H(o4) = fo4g H(x) = fo1g H(l1) = f s1:N1g H(f) = f x:N4g H(s1) = fo1g H(s2) = fo1g H(s3) = fo1g H(l2) = f s2:N2g H(f2) = f a2 :N 0 2g H(x1) = fnilg H(i1) = fnilg H(i2) = fnilg H(l3) = f s3:N3g H(a2) = f g Set object environment A(o1) = f̂2; ̂3g A(o2) = f̂3g A(o3) = f̂;g A(o4) = f̂1g ̂1(m1) = ( ; l1) ̂2(m1) = ( ; l1) ̂3(m1) = ( ; l1) ̂2(m2) = ( ; l2) ̂3(m2) = ( ; l3) Figure 3 Inlining Example N1; N3 does not a ect the analysis. Figure 3 contains also the least solution H, A of the constraints. This analysis reveals the code that may be invoked at any function or method call site. We might take advantage of this control ow information to inline code. Inlining is an optimization technique which replaces a function or a method call with the called body (Jagannathan et al. 1996). The main bene t of inlining is that it eliminates the cost caused by call overhead. Inlining is particularly important for languages which provide objects, as run-time method lookup is a signi cant source of program ine ciency. Inlining code at a call site is sound if there is a unique function or method applicable at that site. For example, we cannot inline x(am2( ) because there is no unique applicable body (see Section 2). Note however, that even if the body were unique, we could inline it only if the language were sequential; in a concurrent setting we could not preserve the semantics of the original code because we would then be inlining a non-self-in icted method invocation, thus changing the process that executes the code. In contrast, inlining s2(am1( ) in the body of method m2 is safe because the body is unique and the operation is self-in icted. This example shows that the bene t from set-based analysis can be substantially enhanced by an in-depth study of self and non-self-in icted operations. (See (Di Blasio 1997) for a rst step.) Colocation of objects in a distributed setting. The following fragment of code describes an object o1 which executes a particular task using a helper object o2. The task starts invoking method do on o1. Method do creates the helper object o2, sets the value of the helper method, and starts a computation in o2 in parallel with the one in o1. When o2 completes the execution of its continue method, it acknowledges o1. Depending on some conditions (omitted in the code) method ack of o1 can either invoke another round of the continue method on itself and o2 or alternatively return a result to some object y. let o1 = h do = s1: a: let o2 = helper ob in hs1 helper = s: a: o2i; o2(a start(s1); s1(s continue; helper = s: a: c; ack = s2: a: : : : let x = (s2(s helper) in x(a continue : : : : : : s2(s continue : : : y(a return( ); continue = s: a: : : : do the task : : : i in o1(a do( ) where helper ob = h start = s3: a:hs3 helped ob = s: x: ai; s3(s continue; helped ob = s: a: c0; continue = s4: a: : : : do the task : : : let x0 = (s4(s helped ob) in x0(a ack( ) i with c, c0 constants of the proper type. If we analyze the code above using the technique described in the previous example, we get for the variables on which methods are invoked the following set environment: H(o2) = fo2g H(s1) = fo1g H(s2) = fo1g H(x) = fc; o2g H(s3) = fo2g H(s4) = fc; o2g H(x0) = fc0; o1g The rst line shows that all method invocations by objects created at the program site denoted by o1, except y(a return( ), refer either to themselves or to objects created at site o2. We have the analogous situation for the methods invoked by o2. In a distributed setting, we can take advantage of this information by locating objects created at program sites o1 and o2 in the same network site. Introducing parallelism. Consider the following object: o = h: : : m = s: a: : : : let x = o0(s n( ) in : : : f(x) : : : i: We can take advantage of the parallelism of our language by transforming the synchronousmethod invocation into an eager invocation following the example in Section 2. However, the transformation makes sense only if the invocation is always non-self-in icted, i.e. the value of o0 is always di erent from the value of the self parameter s. This condition is guaranteed if H(s) \ H(o0) = ;. 5.3 Soundness of the Set Constraints Given a program P and environments H;A which satisfy the set constraints relative to P , proving the soundness of the set constraints means showing that for any con guration g = DD H j j EE to which the initial state for P (gP ) may reduce, H;A are sound approximations of H and , in the senseof De nition 2. Following the outline of the soundness proof in (Flanagan etal. 1995), the proof is done by induction on the length of the reduction. Toprove the inductive step we must rst de ne an invariant, g j=P H;A, for ourcon gurations which contains the relation H; j= H;A and is preserved bythe reduction.De nition 4 Given a con guration g = DD H j j EE, g j=P H;A holds ifH; j= H;A andj=HP H and j=P H:The above de nition says that g is valid with respect to H;A, and P ifeach of its component is valid as well. An object soup is valid for P and H(j=HP H) if for every object in with state [M ], M obeys the constraintson the set environments. A pending queue is valid for P ( j=P H) if everymessage in comes from an asynchronous method invocation in P . The formalspeci cations of these relations can be found in (Di Blasio 1997).The following is the main Lemma we use to prove the induction step in thesoundness theorem.Lemma 1 If g j=P H;A, g 7 ! g0, and H;A satisfy the constraints relativeto P , then g0 j=P H;A.Theorem 1 (Soundness of Constraints) If H;A satis es the set constraintsrelative to P , then P j= H;A.6 CONCLUSIONSIn this paper, we have presented a set-based analysis technique for an im-perative, concurrent object calculus and shown it to be sound. This analysisprovides static information about the values that variables may assume; thisinformation may be used to de ne a program control ow graph, which isthe starting point for most other analysis. We showed some examples thatdemonstrate how this analysis may be applied to problems that arise in aconcurrent setting.This work is intended as a rst step towards the development of formalmethods for program optimization for concurrent object-oriented languages.However, more work needs to be done to establish the applicability and lim-itations of this technique. Our analysis corresponds to what is called 0-CFA(Shivers 1991), the least precise and least complex of a family of control owanalyses. One direction for future research is to improve the precision ande ciency of this analysis, for example, along the lines developed in (Nielsonet al. 1997). Another potential focus for research is the problem of staticallydetecting (non-)self-in icted operations. Such an analysis would attempt todetermine when the target object of an operation is the same as the objectexecuting the request. As the inlining example illustrates, such informationmay be used to avoid the cost of complex remote invocation protocols. REFERENCESAmadio, R. M. (1994) Translating core facile. Tech. Rep. ECRC-1994-3, Eu-ropean Computer-Industry Research Centre.Colby, C. (1995) Analyzing the communication topology of concurrent pro-grams. In Proc. of ACM Symposium on Partial Evaluation andSemantics-Based Program Manipulation, pp. 202{213.Di Blasio, P. (1997) A calculus for concurrent objects: design and control owanalysis. PhD thesis, Universita di Roma \La Sapienza".Di Blasio, P. and Fisher, K. (1996) A calculus for concurrent objects. InProc. of CONCUR'96: Concurrency Theory , vol. LNCS 1119, Springer,pp. 655{670.Fisher, K., Honsell, F. and Mitchell, J. C. (1993) A lambda calculus of objectsand method specialization. Nordic J. Computing (formerly BIT).Flanagan, C., Sabry, A., Dubra, B. and Felleisen, M. (1993) The essence ofcompiling with continuation. In Proc. of PLDI , pp. 237{247.Flanagan, C. and Felleisen, M. (1995) Set-based analysis for full scheme andits use in soft-typing. Tech. Rep. TR95-253, Department of ComputerScience, Rice University.Heintze, N. (1992) Set based program analysis. PhD thesis, Carnegie-MellonUniversity.Holzle, U. and Ungar, D. (1995) Reconciling responsiveness with performancein pure object-oriented languages. ACM Transaction on ProgrammingLanguages and Systems, 18, 4, 355{400.Jagannathan, S. and Wright, A. (1996) Flow-directed inlining. In Proc. ofPLDI'96 , pp. 193{205.Kobayashi, N., Nakade, M. and Yonezawa, A. (1995) Static analysis of com-munication for asynchronous concurrent programming languages. InProc. of SAS'95 .Magic, G. (1996) Telescript technology: Mobile agents. White paper.Mason, I. A. and Talcott, C. L. (1997) A semantically sound actor translation.To appear in ICALP'97.McGraw, G. and Felten, E. W. (1996) Java Security. Wiley Computer Pub-lishing.Nielson, H. and Nielson, F. (1994) Higher-order concurrent programs withnite communication topology. In Proc. of POPL'94.Nielson, H. and Nielson, F. (1997) In nitary control ow analysis: a collectingsemantics for closure analysis. In Proc. of POPL'97.Palsberg, J. and Swartzbach, M. (1991) Object-oriented type inference. InProc. of OOPSLA'91, pp. 146{161.Plevyak, J., Zhang, X. and Chien, A. (1995) Obtaining sequential e ciencyfor concurrent object-oriented languages. In Proc. of POPL'95.Shivers, O. (1991) Controlow analysis of higher-order languages or taminglambda. PhD thesis, Carnegie-Mellon University.